home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 3 / QRZ Ham Radio Callsign Database - Volume 3.iso / digests / tcp / 930030.txt < prev    next >
Internet Message Format  |  1994-06-04  |  8KB
  1. Date: Sat, 30 Jan 93 04:30:09 PST
  2. From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
  3. Errors-To: TCP-Group-Errors@UCSD.Edu
  4. Reply-To: TCP-Group@UCSD.Edu
  5. Precedence: Bulk
  6. Subject: TCP-Group Digest V93 #30
  7. To: tcp-group-digest
  8.  
  9.  
  10. TCP-Group Digest            Sat, 30 Jan 93       Volume 93 : Issue   30
  11.  
  12. Today's Topics:
  13.                  Domain Name Server ( DNS ) question
  14.                       GRINOS 2.0M Bug? (2 msgs)
  15.                            Multi-Port RSPF
  16.                          RCS 5.5 on UCSD.Edu
  17.                                 RDATE
  18.                      RDATE questions and comments
  19.                              WNOS - PMNOS
  20.  
  21. Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
  22. Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
  23. Problems you can't solve otherwise to brian@ucsd.edu.
  24.  
  25. Archives of past issues of the TCP-Group Digest are available
  26. (by FTP only) from UCSD.Edu in directory "mailarchives".
  27.  
  28. We trust that readers are intelligent enough to realize that all text
  29. herein consists of personal comments and does not represent the official
  30. policies or positions of any party.  Your mileage may vary.  So there.
  31. ----------------------------------------------------------------------
  32.  
  33. Date: 30 Jan 93 05:21:54 CST
  34. From: Jack Snodgrass <kf5mg@vnet.ibm.com>
  35. Subject: Domain Name Server ( DNS ) question
  36. To: <TCP-Group@UCSD.Edu>
  37.  
  38.    When a user uses a domain name server to resolve an ip address, NOS
  39. puts an entry in the users's domain.txt file.  It looks like this is a
  40. permanent entry.  Will this entry ever be removed by NOS?  If an IP
  41. address is updated on the DNS, how can the user, using the DNS get the
  42. new IP address if he's made a permeant entry in his domain.txt file?
  43. Thanks.
  44.  
  45. 73's de Jack
  46. | (817) 962-4409 | VM Office Systems | 5 West Kirkwood Blvd | MS 06-05-60 |
  47. |  T/L  522-4409 | Performance Group | Westlake, Tx 76299   | Rm. 6569    |
  48. vnet:jgrass@dalhqic2  ibmmail:usib34cd@ibmmail internet:kf5mg@vnet.ibm.com
  49.  
  50. ------------------------------
  51.  
  52. Date: Fri, 29 Jan 1993 12:48:43 +0000 (GMT)
  53. From: kelvin@thed.uk22.bull.com (Kelvin J. Hill)
  54. Subject: GRINOS 2.0M Bug?
  55. To: tcp-group@ucsd.edu
  56.  
  57. Ed,
  58.    it's not a bug. I put that facility into my version of NOS many moons ago
  59. so that a remote station could kick a NOS system and get thier own netrom
  60. tables updated imediately. This would allow non-24 hour stations to come and
  61. go at will, without waiting for 30 minutes for the next netrom broadcast.
  62. Gerard has taken many of my changes and put them into his version and this is
  63. how you have this functionality.
  64. If you don't like the way it works, just locate the kick responder in the 
  65. source code and remove the line that forces netrom to issue the broadcast.
  66.  
  67. Hope this helps....
  68.  
  69. Kelvin. (G1EMM)
  70.  
  71. ------------------------------
  72.  
  73. Date: Fri, 29 Jan 1993 08:48:32 -0600
  74. From: miltonm@inetnode.austin.ibm.com (Milton Miller)
  75. Subject: GRINOS 2.0M Bug?
  76. To: ed@wa9yyf.ampr.org, tcp-group@ucsd.edu
  77.  
  78. (searching archives of remembered code from reading 3 years ago........)
  79. I seem to recall that the netrom "beacon" was a feature added to the
  80. remote kick command.   Another feature is it does a SMTP kick to that
  81. station.
  82.  
  83.  
  84. I believe the reasoning is if a station has been off the air, then doing
  85. a remote kick should jump-start there getting back into the community.
  86. Thus, sending a nodes broadcast ensures they have netrom routing to you,
  87. the smtp kick will push any mail to them if you have been waiting for them
  88. to come up, and any half-open tcp/netrom/ax25 sessions should be reset or
  89. resumed (if you just lost radio contact, and neither side restarted).
  90.  
  91. I think this was added to NOS a few years ago by Phil.  So, no, its not
  92. a bug, its a feature!   If you don't want netrom to beacon, consider
  93. turning off netrom verbose (I think it has been in all versions for a
  94. while).
  95.  
  96. milton
  97.  
  98. ------------------------------
  99.  
  100. Date: 30 Jan 93 05:25:42 CST
  101. From: Jack Snodgrass <kf5mg@vnet.ibm.com>
  102. Subject: Multi-Port RSPF
  103. To: <TCP-Group@UCSD.Edu>
  104.  
  105.    I think I remember that RSPF was broke when it came to handling
  106. multiple ports.  Is that still the case?  We've got users on both 2 mtrs
  107. and 440.  Some are on both freqs.  Wondering if we can use RSPF in this
  108. environment.  Thanks.
  109.  
  110. 73's  de  Jack - kf5mg
  111. AMPRnet         -  kf5mg@kf5mg.ampr.org       - 44.28.0.14
  112. AX25net         -  kf5mg@kf5mg.#dfw.tx.usa.na - work (817) 962-4409
  113. Internet        -  kf5mg@vnet.ibm.com         - home (817) 488-4386
  114.  
  115. ------------------------------
  116.  
  117. Date: Fri, 29 Jan 93 12:14:46 EST
  118. From: ron@chaos.eng.wayne.edu (Ron Atkinson )
  119. Subject: RCS 5.5 on UCSD.Edu
  120. To: tcp-group@ucsd.edu
  121.  
  122. I uploaded RCS 5.5 on UCSD.Edu.  Brian,  maybe you can moved it to the
  123. hamradio/packet/ka9q  directory for Phil's code or whereever else you
  124. feel it should go.
  125.  
  126. Ron N8FOW
  127.  
  128. ------------------------------
  129.  
  130. Date: Fri, 29 Jan 93 15:14:11 EST
  131. From: crompton@NADC.NADC.NAVY.MIL (D. Crompton)
  132. Subject: RDATE
  133. To: tcp-group@ucsd.edu
  134.  
  135. Looking over the code I suppose I could try - 
  136.  
  137.   i_state=dirps();
  138.   stime(&rtime);
  139.   restore(i_state);
  140.  
  141. Doug
  142.  
  143. ------------------------------
  144.  
  145. Date: Fri, 29 Jan 93 12:36:12 EST
  146. From: crompton@NADC.NAVY.MIL (D. Crompton)
  147. Subject: RDATE questions and comments
  148. To: tcp-group@ucsd.edu
  149.  
  150. I started using RDATE to set the time of our switch to a very
  151. accurate server. In this way users can likewise interrogate the
  152. switch for reasonably accurate time. I say reasonably becasue the
  153. rdate routine does not take into account circuit time. I made a crude
  154. modification to rdate to add some time based on the circuit time. I
  155. also changed the maximum timeout to 2 minutes. I was wondering how
  156. routines distribute time like this synchronize for high accuracy. 
  157. Because of the unreliability of our AMPR circuits it is very hard
  158. to determine one way times.
  159.  
  160. For some reason PC clocks are lousey! My inexpensive wristwatch is
  161. far better. It is actually amazing! It stays within a few seconds over
  162. many months. Most PC's seem to drift in minutes/week or even minutes/day.
  163.  
  164. Another problem that maybe someone could help me with is that the rdate
  165. routine sets the system time with the C stime function. What happens on
  166. my system is that it goes bonkers when this happens. AT commands that
  167. are setup in the table will trigger when they shouldn't etc. What I
  168. think is happenning is that interrupt driven routines that depend on the
  169. system clock are getting bad data while stime is being performed.
  170.  
  171. How do I turn off interrupts around this stime function call? Has anyone else
  172. seen this? Do you think this IS the problem?
  173.  
  174. Doug
  175.  
  176. ------------------------------
  177.  
  178. Date: Fri, 29 Jan 93 10:55:24 EST
  179. From: kz1f@RELAY.WESTBORO.LEGENT.COM
  180. Subject: WNOS - PMNOS
  181. To: tcp-group@ucsd.edu
  182.  
  183. This is really to MikeC, but perhaps others with some history with
  184. PMNOS can answer as well.
  185. Mike, I have not heard of any problems with telnetting into PMNOS 1d.
  186. In fact, I have had people do that at home to connect to the converse
  187. bridge through me. If PMNOS just goes away, that means it crashed. The stack 
  188. prooblem very early on was strictly for T1 and only affected the font mgr. All 
  189. other "spawned processes" get a 4k (1 page) stack. Thats up from the couple of 
  190. hundred needed in a non paging environment. ANyone else experiencing problems 
  191. with telnet and PMNOS? Walt
  192.  
  193.  
  194.  
  195. Walt Corey - kz1f@kz1f.legent.com
  196. ----------------------------------
  197. |                                |
  198. | Space for Rent apply within    |
  199. |                                |
  200. ----------------------------------
  201.  
  202. ------------------------------
  203.  
  204. End of TCP-Group Digest V93 #30
  205. ******************************
  206. ******************************
  207.